[8팀 현지수] Chapter 3-1. 프론트엔드 테스트 코드#63
Open
hyunzsu wants to merge 27 commits intohanghae-plus:hardfrom
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
HARD
7주차 과제 체크포인트
기본과제
질문
문제 원인
MSW 핸들러 내부의 전역 변수가 문제의 원인이고, 테스트 간 데이터 상태가 공유되어 테스트 실행 순서에 따라 결과가 달라지는 동작이 발생했습니다.
독립적 데이터 환경 구축
목적별 핸들러 분리
단일 통합 함수 대신 테스트 목적별로 핸들러를 분리했습니다.
server.use()로 런타임에 필요한 핸들러만 교체하여 메모리 사용량을 줄이고 테스트 의도를 명확하게 했습니다.결과
각 테스트가 독립적인 데이터 환경을 가지게 되어 병렬 실행 시에도 안정적으로 동작합니다.
테스트 실행 순서에 관계없이 항상 동일한 결과를 보장합니다.
심화 과제
과제 셀프회고
기술적 성장
커스텀 훅 테스팅 패턴
renderHook을 통한 훅 독립 테스트
컴포넌트 없이 훅만 독립적으로 실행하고 결과를 검증할 수 있는 개념
act() 함수의 역할
상태 업데이트가 포함된 훅 테스트에서 React 렌더링 사이클과 테스트 환경을 동기화하는 요소
훅 테스트 3단계 패턴
코드 품질
App 컴포넌트를 리팩토링했지만, 아직도 비대합니다.
props drilling을 최소화 할 수 있도록 리팩토링이 필요하다고 생각합니다.
학습 효과 분석
테스트 구조와 AAA 패턴
AAA 패턴
AAA(Arrange-Act-Assert) 패턴을 일관되게 적용했습니다. 각 단계가 명확히 구분되니 테스트를 읽기 쉬워지고 디버깅할 때도 어느 단계에서 문제가 생겼는지 바로 파악할 수 있었습니다.
describe와 it을 통한 테스트 구조화
관련된 테스트들을
describe로 그룹화하면서 테스트가 체계적으로 구성되었습니다. 특히 중첩된describe를 사용해 윤년 처리, 에러 케이스 등 로직별로 분류하니 테스트 의도가 훨씬 명확해졌습니다.Assertion 메서드 선택 기준
처음에는
toBe()만 썼다가 객체 비교에서 실패하는 경우를 겪었습니다.toBe는 원시값 비교,toEqual은 객체/배열 내용 비교라는 차이점을 이해하고 나서 상황에 맞는 assertion을 선택할 수 있게 되었습니다.리뷰 받고 싶은 내용
1. MSW 핸들러 설계의 적절성
현재 테스트 독립성을 위해 setupMockHandlerCreation, setupMockHandlerUpdating, setupMockHandlerDeletion으로 목적별 핸들러를 분리했습니다. 이런 목적별 분리 접근법이 MSW 모범 사례에 부합하는지 검토해주실 수 있나요? 대안으로 하나의 통합 핸들러에서 테스트 ID별로 데이터를 격리하는 방법도 고려해볼 만한지 의견을 듣고 싶습니다.
2. 하드코딩된 대기 시간의 적절성과 대안
API 호출 완료를 위해 1초 하드코딩 대기 후 waitFor로 재검증하는 패턴을 사용했습니다. 이런 이중 대기 방식이 테스트 신뢰성과 실행 시간 측면에서 효율적인지, 아니면 MSW 응답 완료를 더 정확히 감지할 수 있는 방법이 있는지 피드백 부탁드립니다.